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The possibility of corruption of critical information required in the operation of a host computer (10) is reduced by storing 
the critical information in a device (22) ; communicating authorization information between the device (22) and the host computer 
(10); and causing the device (22), in response to the authorization information, to enable the host computer (10) to read the criti- 
cal information stored in the device (22). The device (22) includes a housing, a memory (36) within the housing containing infor- 
mation needed for startup of the host computer (10), and communication channel for allowing the memory (36) to be accessed ex- 
ternally of the housing. The device (22) is initialized by storing the critical information in memory (36) on the device (22), storing 
authorization information in memory (36) on the device (22), and configuring a microprocessor (34) in the device (22) to release 
the critical information to the host computer (10) only after completing an authorization routine based on the authorization infor- 
mation. 
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SYSTEM FOR PROTECTING COMPUTERS VTA 
INTELLIGENT TOKENS OR SMART CARDS 
Background of the Invention 
5 This invention relates to reducing the possibility 

of corruption of critical information required in the 
operation of a computer system. In particular , the 
invention is aimed at preventing boot-sector computer 
viruses and protecting critical executable code from 
10 virus infection. 

The process of starting up a computer, i.e., 
booting or boot-strapping a computer is well known, but 
we describe aspects of it here for the sake of clarity 
and in order to define certain terms and outline certain 
15 problems which are solved by this invention- 

Fig. l depicts a typical computer system 10 with 
central processing unit (CPU) 12 connected to memory 14. 
Display 18, keyboard 16, hard disk drive 17, and floppy 
disk drive 19 are connected to computer system 10. 
20 A typical computer system such as shown in Fig. l 

uses a program or set of programs called an operating 
system (OS) as an interface between the underlying 
hardware of the system and its users. A typical OS, 
e.g., MS-DOS Version 5.0, is usually divided into at 
25 least two parts or levels. The first level of the OS, 
often referred to as the kernel of the OS, provides a 
number of low-level functions called OS primitives which 
interact directly with the hardware. These low-level 
primitives include, for example, functions that provide 
30 the basic interface programs to the computer system's 
keyboard 16, disk drives 17, 19, display 18, and other 
attached hardware devices. The OS primitives also 
include programs that control the execution of other 
programs, e.g., programs that load and initiate the 
35 execution of other programs. Thus, for example, if a 
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user wishes -to run a word-processing program or a game 
program, it is the primitives in the OS kernel which load 
the user's program from a disk in one of the attached 
disk drives 17, 19 into the computer system's memory 14 
5 and begins executing it on CPU 12. 

The second level of the OS typically consists of a 
number of executable programs that perform higher-level 
(at least from a user's perspective) system related 
tasks , e.g., creating, modifying, and deleting computer 

10 files, reading and writing computer disks or tapes, 

displaying data on a screen, printing data, etc. These 
second-level OS programs make use of the kernel's 
primitives to perform their tasks. A user is usually 
unaware of the difference between the kernel functions 

15 and those which are performed by other programs. 

A third level of the OS, if it exists, might 
relate to the presentation of the OS interface to the 
user. Each level makes use of the functionality provided 
by the previous levels, and, in a well designed system, 

20 each level uses only the functionality provided by the 

immediate previous level, e.g., in a four level OS, level 
3 only uses level 2 functions, level 2 only uses level 1 
functions, level 1 only uses level 0 functions, and level 
0 is the only level that uses direct hardware 

25 instructions . 

Fig. 2 depicts an idealized view of a four level 
OS, with a level for hardware (level 0) 2, the kernel 
(level 1) 4, the file system (level 2) 6, and the user 
interface (level 3) 8. 

30 An OS provides computer users with access and 

interface to a computer system. Operating systems are 
constantly evolving and developing to add improved 
features and interfaces. Furthermore, since an OS is 
merely a collection of programs (as described above) , the 

35 same computer system, e.g. that shown in Fig. 1, can have 
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a different OS running on it at different times. For 
example, the same IBM personal computer can run a 
command-line based OS, e.g., MS-DOS V5.0, or a graphical, 
icon based OS, e.g., MS-Windows 3.0. 
5 In order to deal with the evolution of operating 

systems (as well as to deal possible errors in existing 
operating systems) computer system manufacturers have 
developed a multi-stage startup process, or boot process, 
for computers. Rather than build a version of the OS 
10 into the system, the multi-stage boot process works as 
follows: 

A boot program is built into the computer system 
and resides permanently in read-only memory (ROM) or 
programmable read-only memory (PROM) (which is part of 

i5 memory 14) on the system. Referring to Fig. 4, a 

computer system's memory 14 can consist of a combination 
of Random Access Memory (RAM) 24 and ROM 26. The ROM (or 
PROM) containing the boot program is called the boot ROM 
28 (or boot PROM ) . A boot program is a series of very 

20 basic instructions to the computer's hardware that are 
initiated whenever the computer system is powered up (or, 
on some systems, whenever a certain sequence of keys or 
buttons are pressed) . The specific function of the boot 
program is to locate the OS, load it into the computer's 

25 memory, and begin its execution. These boot programs 
include the most primitive instructions for the machine 
to access any devices attached to it, e.g., the keyboard, 
the display, disk drives, a CD-ROM drive, a mouse, etc. 

To simplify boot programs and to make their task 

30 of locating the OS easy, most computer system 

manufacturers adopt conventions as to where the boot 
program is to find the OS. Two of these conventions are: 
the OS is located in a specific location on a disk, or 
the OS is located in a specific named file on a disk. 

35 The latter approach is adopted by the Apple Macintosh™ 
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computer where the boot program looks for a file named 
"System" (which contains, e.g., Apple's icon-based 
graphical OS) on disks attached to the computer. The 
former approach, i.e., looking for the OS in a particular 
5 location, e.g., on a disk, is the one currently used by 
most I.B.M. personal computers (and clones of those 
systems) . In these systems the boot program looks, in a 
predetermined order, for disks in the various disk drives 
connected to the system (many computer systems today have 

10 a number of disk drives, e.g., a floppy-disk drive, a CD- 
ROM, and a hard-disk drive) . Once the boot program finds 
a disk in a disk drive, it looks at a particular location 
on that disk for the OS. That location is called the 
boot sector of the disk. 

15 Referring to Fig. 3, a physical disk 9 is divided 

into tracks which are divided up into sectors 11 (these 
may actually be physically marked, e.g., by holes in the 
disk, in which case they are called hard-sectored, but 
more typically the layout of a disk is a logical, i.e. 

20 abstract layout) . The boot sector is always in a 

specific sector on a disk, so the boot program knows 
where to look for it. Some systems will not allow 
anything except an OS to be written to the boot sector, 
others assume that the contents of the boot sector could 

25 be anything and therefore adopt conventions, e.g., a 
signature in the first part of the boot sector, that 
enables the boot pro g ram to determine whether or not it 
has found a boot, sector with an OS. If not it can either 
give up and warn the user or it can try the next disk 

30 drive in its predetermined search sequence. 

Once the boot program has determined that it has 
found a boot sector with an OS (or part of an OS) , it 
loads (reads) into memory 14 the contents of the boot 
sector and then begins the execution of the OS it has 

35 just loaded. When the OS begins execution it may try to 
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locate more files, e.g., the second level files described 
above, before it allows the user access to the system. 
For example, in a DOS-based system, the program in the 
boot sector, when executed, will locate, load into 
5 memory, and execute the files, IO.SYS, MSDOS.SYS, 

COMMAND.COM, CONFIG.SYS, and AUTOEXEC.BAT. (Similarly, 
in a multi-level system, each level loads the next one, 
e.g., the Hewlett-Packard Unix™ -like System HPUX has at 
least 4 levels which get loaded before the user is 

10 presented with an interface to the computer system. ) 

The process of booting a computer system is 
sometimes called the boot sequence - Sometimes the boot 
sequence is used to refer only to the process executed by 
the first boot program. 

15 Computer viruses aimed at personal computers (PCs) 

have proliferated in recent years. One class of PC 
viruses is known as boot infectors . These viruses infect 
the boot-sectors of floppy or hard disks in such a way 
that when the boot sequence of instructions is initiated, 

20 the virus code is loaded into the computer's memory. 

Because execution of the boot sequence precedes execution 
of all application programs on the computer, antiviral 
software is generally unable to prevent execution of a 
boot-sector virus. 

25 Recall, from the discussion above, that the boot 

program loads into memory the code it finds in the boot 
sector as long as that code appears to the boot program 
to be valid. 

In addition to the boot infector class of viruses, 
30 there is another class of viruses called file infectors 
which infect executable and related (e.g., overlay) 
files. Each class of virus requires a different level or 
mode of protection. 

File infector viruses typically infect executable 
35 code (programs) by placing a copy f themselves within 
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the program; when the infected program is executed so is 
the viral code. In general, this type of virus code 
spreads by searching the computer's file system for other 
executables to infect, thereby spreading throughout the 
5 computer system. 

One way that boot-sector viruses are spread is by 
copying themselves onto the boot-sectors of all disks 
used with the infected computers. When those infected 
disks are subsequently used with other computers, as is 

10 often the case with floppy disks, they transfer the 

infection to the boot-sectors of the disks attached to 
other machines. Some boot— sector viruses are also file 
infectors. These viruses copy themselves to any 
executable file they can find. In that way, when the 

15 infected file is executed it will infect the boot sectors 
of all the disks on the computer system on which it is 
running. 

Recall, from the discussion above, that an OS may 
consist of a number of levels, some of which are loaded 

20 from a boot sector, and others of which may be loaded 
into the system from other files on a disk. It is 
possible to infect an OS with a virus by either infecting 
that part of it the resides in the boot sector (with a 
boot-sector virus) or by infecting the part of it that is 

25 loaded from other files (with a f ile-inf ector virus) , or 
both. Thus, in order to maintain the integrity of a 
computer operating system and prevent viruses from 
infecting it, it is useful and necessary to prevent both 
boot-sector and f ile-inf ector viruses. 

30 Work to develop virus protection for computers has 

often been aimed at PCs and workstations, which are 
extremely vulnerable to virus infection. The many 
commercial packages available to combat and/or recover 
from viral infection attest to the level of effort in 

35 this area. 
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Unfortunately, computer virus authors produce new 
versions and strains of virus code far more rapidly than 
programs can be developed to identify and combat them. 
Since viruses are typically recognized by a "signature", 
5 i.e., a unique sequence of instructions , new viral code 
may at times be difficult to identify. Existing 
signature-based virus detection and eradication programs 
require knowledge of the signature of a virus in order to 
detect that virus. 

10 Current systems employ different strategies to defend 
against each type of virus. In one of these strategies 
to protect against boot infectors, first a clean 
(uninfected) copy of the boot-sector is made and kept on 
a backup device, e.g., a separate backup disk. 

15 Subsequent attempts to write to the boot-sector are 

detected by the anti-viral software in conjunction with 
the OS and the user is warned of potential problems of 
viral infection. Since reading from and writing to a 
disk is a function performed by the OS kernel, it knows 

20 when a disk is written to and which part of the disk is 
being written. Anti-virus software can be used to 
monitor every disk write to catch those that attempt to 
modify the boot sector. (Similarly, in systems which 
keep the OS in a particular named file, every attempt to 

25 modify that file can be caught) . At this point, if the 
boot-sector has been corrupted the user can replace it 
with a clean copy from the backup disk. 

To inhibit file infectors an integrity check, 
e.g., a checksum is calculated and maintained of all 

30 execu tables on the system, so that any subsequent 

modification may be detected. A checksum is typically an 
integral value associated with a file that is some 
function of the contents of the file. In the most common 
and simple case the checksum of a file is the sum of the 

35 integer values obtained by considering each byte of data 
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in the file as an integer value* Other more complicated 
schemes of determining a checksum are possible , e.g., the 
sum of the bytes in the file added to the size of the 
file in bytes. Whatever the scheme used, a change in the 
5 file will almost always cause a corresponding change in 
the checksum value for that file, thereby giving an 
indication that the file has been modified. If a file is 
found with a changed checksum, it is assumed to be 
infected. It can be removed from the computer system and 
10 a clean copy can restored from backup. 

Many viruses use the low-level primitive functions 
of the OS, e.g., disk reads and writes, to access the 
hardware. As mentioned above, these viruses can often be 
caught by anti-viral software that monitors all use of 
15 the OS's primitives. To further complicate matters 

however, some viruses issue machine instructions directly 
to the hardware, thus avoiding the use of OS primitive 
functions. Viruses which issue instructions directly to 
the hardware can bypass software defenses because there 
20 is no way that their activities can be monitored. 

Further, new self -encrypting (stealth) viruses may be 
extremely difficult to detect, and thus may be overlooked 
by signature recognition programs. 

One approach to the boot integrity problem is to 
25 place the entire operating system in read-only memory 

(ROM) 26 of the computer 10. However, this approach has 
disadvantages in that it prevents modifications to boot 
information, but at the cost of updatability. Any 
upgrades to the OS require physical access to the 
30 hardware and replacement of the ROM chips. It is also 
the case that as operating systems become more and more 
sophisticated, they become larger and larger. Their 
placement in ROM would require larger and larger ROMs. 
If user authentication is added to the boot program, 
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passwords may be difficult to change and operate on a per 
machine rather than a per user basis. 

Some Operating Systems have so-called login 
programs which require users to enter a password in order 
5 to use the system. These login programs, whether stand- 
alone or integrated with an antiviral program, suffer 
from the same timing issues as previously mentioned. 
Also since most PCs provide a means of booting from 
alternate devices, e.g., a floppy disc drive, login 

10 programs can often be trivially defeated. 

firmrniary the Invention 
In general, in one aspect, the invention features 
reducing the possibility of corruption of critical 
information required in the operation of a computer, by 

15 storing the critical information in a device; 

communicating authorization information between the 
device and the computer; and causing the device, in 
response to the authorization information, to enable the 
computer to read the critical information stored in the 

20 device. 

Embodiments of the invention include the following 
features. The authorization information may be a 
password entered by a user and verified by the device (by 
comparison with a pre-stored password for the user) ; or 

25 biometric information (e.g. a fingerprint) about a user. 
The device may be a pocket-sized card containing the 
microprocessor and the memory (e.g., a smart card) . The 
critical information may include boot-sector information 
used in starting the computer; or executable code; or 

30 system data or user data; or file integrity information. 
The computer may boot itself from the critical 
information read from the device by executing modified 
boot code (stored as a BIOS extension) in place of normal 
boot code. 
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The device may pass to the computer secret 
information shared with the computer (e.g., a host access 
code) ; the computer validates the shared secret 
information. The authorization information may be file 
5 signatures for executable code; or a user's cryptographic 
key. 

A communication link between the device and the 
computer carries the authorization information and the 
critical information. 

10 In general, in another aspect, the invention 

features initializing a device for use in reducing the 
possibility of corruption of critical information 
required in the operation of a computer, by storing the 
critical information in memory on the device, storing 

15 authorization information in memory on the device, and 

configuring a microprocessor in the device to release the 
critical information to the computer only after 
completing an authorization routine based on the 
authorization information. 

20 In general, in another aspect, the invention 

features a portable intelligent token for use in 
effecting a secure startup of a host computer. The token 
includes a housing, a memory within the housing 
containing information needed for startup of the host 

25 computer, and a communication channel for allowing the 
memory to be accessed externally of the housing. 

In embodiments of the invention, the memory also 
contains a password for authorization , and a processor 
for comparing the stored password with externally 

30 supplied passwords. The memory may store information 
with respect to multiple host computers. 

Among the advantages of the invention are the 
following. 

The invention provides extremely powerful security 
35 at relatively low cost, measured b th in terms of 
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purchase price and setup time. The additional hardware 
required is nominal, initial setup is one-time only, and 
upgrades require no hardware access — provided the user 
has the proper authentication. The invention obviates 
5 the need to defend against boot infectors and greatly 
reduces the risk to selected executables. The invention 
eliminates the PC's vulnerability to boot infectors, 
ensures the integrity of selected data, and guarantees 
the reliability of executables uploaded from the 

10 smartcard. Due to the authentication which occurs in the 
boot sequence, the possibility of sabotage or 
unauthorized use of the PC is restricted to those users 
who possess both a properly configured smart card and the 
ability to activate it. 

15 Other advantages and features will become apparent 

from the following description and from the claims. 

Description 

Fig. 1 is a diagram of a typical computer system 
using the invention; 
20 Fig. 2 depicts the levels of an operating system; 

Fig. 3 shows the layout of a computer disk; 

Fig. 4 is a view of the memory of the computer 
system shown in Fig. 1; 

Figs. 5-6 show, schematically, a smartcard and its 

25 memory; 

Figs. 7-10 are flow diagrams of boot processes. 

The invention makes use of so-called intelligent 
tokens to store a protected copy of the file that is 
usually stored in a disk boot sector, along with other 
30 file integrity data. 

Intelligent tokens are a class of small {pocket- 
sized) computer devices which consist of an integrated 
circuit (IC) mounted on a transport medium such as 
plastic. They may also include downsized peripherals 
35 necessary for the token's application. Examples of such 
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peripherals are keypads, displays, and biometric devices 
(e.g., thumbprint scanners). The portability of these 
tokens lends itself to security-sensitive applications. 
A subclass of intelligent tokens are ic cards, 
5 also known as smartcards. The physical characteristics 
of smartcards are specified by The International 
Standards Organization (ISO) (described in International 
Standard 7816-1, Identification Cards — Integrated 
Circuit(s) with Contacts — Physical Characteristics, 

10 International Standards Organization, 1987) . In brief, 
the standard defines a smartcard as a credit card sized 
piece of flexible plastic with an IC embedded in the 
upper left hand side. Communication with the smartcard 
is accomplished through contacts which overlay the IC 

15 (described in International Standard 7816-2, 

Identification Cards — Integrated Circuit (s) With 
Contacts — Dimensions and Location of the Contacts, 
International Standards Organization , 1988) . Further, 
ISO also defines multiple communications protocols for 

20 issuing commands to a smartcard (described in 

International Standard 7816-3, Identification Cards — 
Integrated Circuit (s) With Contacts — Electronic Signals 
and Transmission Protocols, International Standards 
Organization, 1989) . While all references to smartcards 

25 here refer to ISO standard smartcards, the concepts and 
applications are valid for intelligent tokens in general. 

The capability of a smartcard is defined by its 
IC. As the name implies, an integrated circuit consists 
of multiple components combined within a single chip. 

30 Some possible components are a microprocessor, non-static 
random access memory (RAM) , read only memory (ROM) , 
electrically programmable read only memory (EPROM) , 
nonvolatile memory (memory which retains its state when 
current is removed) such as electrically erasable 

35 programmable read only memory (EEPROM) , and special 
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purpose coprocessor (s) . The chip designer selects the 
components as needed and designs the chip mask. The chip 
mask is burned onto the substrate material, filled with a 
conductive material, and sealed with contacts protruding. 
5 Fig. 5 depicts a typical smartcard 22 with IC 32 

which contains a CPU 34 and memory 36. Memory 36 is made 
up of a ROM 38 and an EEPROM 40. 

The current substrate of choice is silicon. 
Unfortunately silicon, like glass, is not particularly 
10 flexible; thus to avoid breakage when the smartcard is 
bent, the IC is limited to only a few millimeters on a 
side. The size of the chip correspondingly limits the 
memory and processing resources which may be placed on 
it. For example, EEPROM occupies twice the space of ROM 
15 while RAM requires twice the space of EEPROM. Another 
factor is the mortality of the EEPROM used for data 
storage, which is generally rated for 10,000 write cycles 
and deemed unreliable after 100,000 write cycles. 

Several chip vendors (currently including Intel, 
20 Motorola, SGS Thompson, and Hitachi) provide ICs for use 
in smartcards. In general, these vendors have adapted 
eight-bit micro-controllers, with clock rates of 
approximately 4 megahertz (Mhz) for use in smartcards. 
However, higher performance chips are under development. 
25 Hitachi's H8/310 is representative of the capabilities of 
today's smartcard chips. It provides 256 bytes of RAM, 
10 kilobytes (K) of ROM, and 8K of EEPROM. The 
successor, the H8/510, not yet released, claims a 16-bit 
10 Mhz processor, and twice the memory of the H8/310. It 
30 is assumed that other vendors have similar chips in 
various stages of development. 

Due to these and other limits imposed by current 
technology, tokens sure often built to application- 
specific standards. For example, while there is 
35 increased security in incorporating peripherals with the 
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token, the resulting expense and dimensions of self- 
contained tokens is often prohibitive. Because of the 
downsizing required for token- based peripherals, there 
are also usability issues involved. From a practical 
5 perspective, peripherals may be externally provided as 
long as there is reasonable assurance of the integrity of 
the hardware and software interface provided. The 
thickness and bend requirements for smartcards do not 
currently allow for the incorporation of such 

10 peripherals, nor is it currently feasible to provide a 
constant power supply. Thus, today's smartcards must 
depend upon externally provided peripherals to supply 
user input as well as time and date information, and a 
means to display output. Even if such devices existed 

15 for smartcards, it is likely that cost would prohibit 
their use. For most applications it is more cost 
effective to provide a single set of high cost 
input /output (I/O) devices for multiple cards (costing 
$15-$20 each) than to increase smartcard cost by orders 

20 of magnitude. This approach has the added benefit of 
encouraging the proliferation of cardholders. 

Smartcards are more than adequate for a variety of 
applications in the field of computer security (and a 
number of applications outside the field) . The National 

25 Institute of Standards and Technology (NIST) has 

developed the Advanced Secure Access Control System 
(ASACS) which provides both symmetric (secret key) and 
asymmetric (public key) cryptographic algorithms on a 
smartcard (described in An Overview Of The Advanced 

30 Smartcard Access Control System, J. Dray and D. Balenson, 
Computer Security Division/ Computer Systems Laboratory, 
National Institute of Standards and Technology, 
Gaithersburg, Maryland) . The ASACS utilizes DBS (Data 
Encryption Standard) (described in Data Encryption 

35 Standard — FIPS Publicati n 46-1, National Institute f 
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Standards and Technology (formerly NBS) , Gaithersburg, 
Maryland) for login authentication using the 9.26 
standard authentication protocol (defined in Financial 
Institution Sign-on Authentication For Wholesale 
5 Financial Systems [DES-based user authentication 

protocols], ANSI X9.26, X9 Secretariat, American Bankers 
Association, Washington, D.C.). It further offers a 
choice of RSA (described in R. L. Rivest, A. Shamir, L. 
M. Adleman, "A Method for Obtaining Digital Signatures 

10 and Public Key Cryptosystems , " Communications of the ACM, 
pp. 120-126, Volume 21, Number 2, February 1978) or DSA 
(described in "The Digital Signature Standard Proposed by 
NIST", Communications of the ACM, Volume 35, No. 7, July, 
1992, pp. 36-40) for digital signatures. 

15 The ASACS card provides strong security because 

all secret information is utilized solely within the 
confines of the card. It is never necessary for a secret 
or private key to be transferred from the card to a host 
computer; all cryptographic operations are performed in 

20 their entirety on the card. Although the current H8/310 
equipped card requires up to 20 seconds to perform sign 
and verify operations, a new card developed for the 
National Security Agency (NSA) is capable of performing 
the same operations in less than a second. The NSA card 

25 is equipped with an Intel 8031 processor, a Cylink CY513 
modular exponentiator (coprocessor) , 512 bytes of RAM and 
16 Kbytes of EEPROM. Since both the RSA and DSA 
algorithms are based on modular exponentiation, it is the 
Cylink coprocessor which accounts for the NSA card's 

30 greatly enhanced performance. 

Trusted Information Systems (TIS) , a private 
computer security company, is currently integrating 
smartcards for use with privacy enhanced computer mail in 
a product called TISPEM. A user-supplied smartcard is 

35 used to store the user's private key and in addition 
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provides service calls for digital signatures and 
encryption so that all operations involving the private 
key are performed on the card. In this way the private 
key need never leave the card. Thus, a TISPEH user can 
5 sit down at any terminal which has access to the 

application software (and a smartcard reader) and read 
encrypted mail and send signed messages without fear of 
compromising his or her private key. 

Referring to Figs. 5 and 6, in the invention, a 

10 smartcard' s memory 36 contains an propriety operating 
system and software programs to enforce access control 
(in ROM 38) together with critical information 42, 44, 46 
usually stored in the host's boot-sector, directory, and 
executables (in EEPROM 40) . The amount of memory 

15 available on the token will dictate the amount of data 
which may be stored. In addition, other sensitive or 
private information 48 may be stored to ensure its 
integrity. 

One aspect of l.B.M. personal computers and their 

20 clones is that the computer systems are not all 

identically configured. Some computer systems may have 
devices, e.g., display monitors or optical disks, that 
other systems do not have. Some of these computer 
systems have slots which can accept addin boards which 

25 can be used to enhance the system by, for example 

increasing its speed or the resolution of its display. 
In order to overcome the complications introduced by non- 
uniformity of computer platforms, a set of functions that 
provide an interface to the low-level input/output (I/O) 

30 system is provided. In the I.B.M. PC systems this system 
is called the Basic Input Output System (BIOS) and 
resi d es in the EPROM and is loaded by the boot program 
before it loads the program from the boot sector, 

l.B.M. PCs are expandable and can have new devices 

35 attached to them using cards inserted into slots in the 
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computer's chassis. A new device or card may need to 
extend the interface to the low-level I/O system, i.e., 
to extend the BIOS. To do this it uses a BIOS Extension . 
The system takes advantage of the following 
5 feature of the PC's boot sequence: after loading the BIOS 
but before loading the boot sector, the boot program 
examines each expansion slot in the computer, looking for 
a BIOS extension. If it finds one it hands over control 
to that extension. In a typical PC system the BIOS 

10 extension would load its functions into the system and 
then pass control back to the boot program. After 
checking all extension slots for BIOS extensions the boot 
program then begins looking in the disk drives for a disk 
with a boot sector from which to boot. 

15 Fig. 7 describes the boot sequence of a PC. When 

the boot sequence is started 50 (either by cycling the 
power of the computer or by pressing a particular 
sequence of keys on the keyboard) the boot program in ROM 
28 of the computer system loads the BIOS code 52 into 

20 memory 14. This BIOS code allows the program to interact 
with attached devices. The boot program then examines 
each slot 54 (by address) in turn to determine if it 
contains a board with a BIOS extension 56. If the boot 
program finds a slot with a BIOS extension then it loads 

25 and executes the code associated with that BIOS extension 
58. After the BIOS extension's code is executed, control 
is passed back to the boot program to examine the next 
slot address 54. When all slots have been examined the 
boot program then tries to find a boot disk , i.e., a disk 

30 with a boot sector 60. (I.B.M. PCs are configured to 
look for a boot disk starting in the floppy drives and 
then on the hard drives.) Once a boot disk is found, its 
boot sector is loaded and executed 62. 
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A Smartcard-Based Operating System 
A prototype of the invention, also referred to 
herein as The Boot Integrity Token System (BITS) , has 
been developed to provide computer boot integrity and 
5 enforce access control for an IBM or compatible system 
(PC-BITS) , although the technology described is 
applicable to a wide variety of other computer systems. 

Referring again to Fig. 1, the basic idea behind 
BITS is that the host computer system 10 will actually 
10 boot itself from a smartcard 22. Since the smartcard 22 
can be readily configured to require user authentication 
prior to data access, it provides an ideal mechanism to 
secure a host computer. Thus, if critical information 
required to complete the boot sequence is retrieved from 
15 a smartcard, boot integrity may be reasonably assured. 
The security of the system assumes the physical security 
of the host either with a tamper-proof or tamper-evident 
casing, and the security of the smartcard by its design 
and configuration. If an attacker can gain physical 
20 access to the hardware, it is impossible to guarantee 
system integrity. 

Referring to Figs. 1 and 4-6, the PC-BITS 
prototype consists of an 8 -bit addin board 30, a 
smartcard drive 20 (reader /writer) which mounts in a 
25 floppy bay of computer system 10, configuration as well 
as file signature validation software, and a supply of 
smart cards. The board 30 contains a special boot PROM 
which is loaded with a program which interfaces to the 
smartcard reader. Further, the board is configurable to 
30 set an identifier for the host. 

Installation and configuration of the host can be 
accomplished in minutes. The process involves insertion 
of the addin board and the equivalent of the installation 
of a floppy drive. Once installed, the computer will not 
35 complete the boot sequence without a valid user 
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authentication to a properly configured smartcard. The 
reason for this is that the addin board 30 is a BIOS 
Extension board. Recall from the discussion above, with 
reference to Fig. 7, that the boot program loads and 
5 executes any and all BIOS extensions 58 before it looks 
for a boot disk 60. The addin board 30 takes control 
from the boot program when its BIOS extension is loaded, 
but it does not return control back to the boot program. 
Thus, the modified boot process is like that depicted in 

10 Fig. 8, where the process of looking for and loading a 

boot sector does not take place under control of the boot 
program, but under the control of the modified boot 
program on the BIOS Extension card. 

During system startup, two authentications must be 

15 successfully performed to complete the boot sequence. 

First, the user enters a password which is checked by the 
smartcard to confirm that the user is authorized to use 
that card. If successful, the smartcard allows the PC to 
read the boot-sector and other information from the 

20 smart-card memory. To authenticate the smartcard to the 
host, the card must also make available a secret shared 
with the host, in this case the configurable host 
identifier. Table l illustrates these transactions. If 
both the user and card authentication are successful, the 

25 boot sequence completes, and control is given to the PC 
operating system — some or all of which has been 
retrieved from the smartcard. The user may then proceed 
to utilize the PC in the usual fashion, uploading 
additional information (i.e., applications or application 

30 integrity information) from the smartcard as needed. 
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Step 


Action 


Implementation 


0 


Insert card and power up 
the host 


Apply power and reset 
card 


1 


Authenticate user and 
present data to the 
smartcard 


Present user password to 
the smartcard 


2 


Authenticate the card to 
the host 


Host reads shared secret 
from the smartcard 


3 


Upload boot information 


Host reads boot-sector 
from the smartcard 


4 


Integrity check host- 
resident boot 
files and complete boot 
sequence if successful 


Host computes file- 
checksum which the 
smartcard encrypts to 
form a signature; this 
value is compared with 
the signature stored on 
the card 



Table 1: PC-BITS System Startup 

The card is expected to contain critical data such 
as digital file signatures for system executables and the 

10 user's cryptographic keys. Comparing executable file 
signatures with those stored on the smartcard provides a 
virus detection mechanism which is difficult to defeat. 
This approach is consistent with a recent trend to 
validate file integrity rather than solely scan for known 

15 virus signatures. 

Refer now to Figs. 9-10 , which show the control 
flow of the modified boot sequence from the point of view 
of the computer system said the smartcard respectively. 
The flow diagram in Fig. 9 shows the control flow of the 

20 modified boot program loaded from the BIOS Extension 
addin card in step 58 (Fig. 8) of the original boot 
sequence. Fig. 10 shows the processing that occurs 
(during the boot sequence) on the CPU 34 of the smart car d 
22 while it is in the smartcard reader 20. 

25 The modified boot program (the BIOS extension) 

prompts the user for a password 60 on display 18. The 
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password is read 62 from keyboard 16 and sent to the 
smartcard 22. At the same time, the smartcard is waiting 
for a password 92. When the smartcard 22 gets a password 
94 from the computer system 10 it validates the password 
v 5 96 using whatever builtin validation scheme comes with 

the smartcard. If the password is invalid then the 
smartcard 22 returns a "NACK" signal 100 to the computer 
system 10, disallows reading of its data 102 and 
continues to wait for another password 92. (In some 
10 systems a count is kept of the number of times an invalid 
password is entered, with only a limited number of failed 
attempts allowed before the system shuts down and 
requires operator or admi n istrator intervention.) If the 
password is valid then the smartcard 22 returns an "ACK" 
15 signal 98 to the computer system 10 and allows reading of 
the data in its memory and files 104. 

The computer system 10 waits for the response 66 
from the smartcard 22 and then bases its processing on 
the returned result 68. If the password was invalid 
20 (i.e., the smartcard returned an "NACK" signal) then the 
user is once again prompted for a password 60 (recall 
again the discussion above about limiting the number of 
attempts.) If the password is valid the user has been 
authenticated to the smartcard and now the computer 
25 system attempts to authenticate the card for the system. 
It does this (in step 70) by reading a host access code 
46 from EEPROM 40 of the smartcard 22. (The host access 
code is one of the items of data put on the smartcard by 
the system administrator during system configuration.) 
30 The host access code 46 from the smartcard is compared to 
the one that the system has stored about itself 72. If 
they are unequal then this smartcard 22 is not allowed 
for this host computer system 10 and the boot process is 
terminated 74. (Note that this termination ends the 
35 entire boot process — the boot program does not then try 
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to boot: from a disk) . If the check at step 72 finds the 
codes to be equal then the card is authenticated to the 
host and the boot sector 42 from EEPROM 40 of smartcard 
22 is read (step 76) into memory 14 of computer system 
5 10. 

Recall that, because of the limited size of the 
memory on smartcards today, it is not yet possible to 
store all the information and files for an OS the size 
of, e.g., MS-DOS on a smartcard. Therefore the other 

10 files will have to be read from a disk or other storage 
device* It is f however, still possible to ensure their 
integrity by the use of integrity information, e.g., 
checksums for the files, stored on the smartcard (by a 
system administrator) . 

15 In step 78 the BIOS Extension program reads the 

file integrity information 44 from the EEPROM 40 of the 
smartcard 22. Then, for each file whose integrity is 
required, e.g., IO.SYS, etc, the integrity information 
for that file is validated (step 80) . If the OS files 

20 cure found to be invalid 82 then and error is reported 84 
to the user on display 18. If the error is considered to 
be severe 88 then the boot process terminates 90. (The 
determination of what constitutes "severe" is made in 
advance by the system administrator based on the security 

25 requirements of the system. In some systems no file 

changes are allowed, in others some specific files may be 
modified, but not others.) 

If the file integrity information is valid (or the 
error is not considered severe) then the boot sector that 

30 was loaded from the smartcard (in step 76) is executed 
86. At this point the boot process will continue as if 
the boot sector had been loaded from a disk (as in the 
unsafe system) . 

In the BITS system, cards are configured and 

35 issued by a security officer using the software provided 
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— the current prototype is written in C to improve 
portability. 

Configuration entails the loading onto the 
smartcard of the boot sector 42 as well as digital 
5 signatures for boot files stored on the host 44. At the 
time of issue, it is necessary to specify the machine or 
set of machines 46 that the user to whom the card is 
being issued will be granted access so that a host key 
may be loaded. File integrity information and portions 
10 of the host operating system are also loaded onto the 

smartcard at this time 44. All data is read protected by 
the user's authentication (e.g., cannot be read unless 
the user password is presented correctly) , and write 
protected by the security officer authentication. This 
15 arrangement (depicted in Table 2) prevents users from 

inadvertently or deliberately corrupting critical data on 
the smartcard. 

Smart cards may be issued on a per host, per group, 

or per site basis depending on the level of security 
20 desired. Since the secret shared by the host and card is 
conf igurable on the host, it is possible to issue 
smartcards in a one-to-one, many- to-one, or many-to-many 
fashion. A one-to-one mapping of users to hosts 
corresponds to securing a machine for a single user. 
25 Analogously, many-to-one allows the sharing of a single 
machine, and many-to-many allows for the sharing of 
multiple machines among an explicit set of users. One- 
to-many is a possible, but usually wasteful, mapping of 
computer resources. 
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Step 


Action 


Implementation 


0 


Security officer 
creates user and 
security officer 
accounts on card 


Present manufacturer password 
and load user-specified secret 
codes for accounts. 


1 


Load boot-sector onto 
card 


Create a file readable under 
the user password and writable 
under the security officer 

partition boot record. 


2 


Compute and load 
signatures for 
selected files 


For each file compute a hash 
which is encrypted by the card. 
This signature together with 
the file name is stored on the 
card. 


3 


Load host 

authentication 

information 


Create a file readable under 
the user password and writable 
under the security officer 
password and write a secret to 
be shared with the host. 



Table 2: BXTS Smartcard Configuration 



The effectiveness of BITS is limited by the 
feasibility of storing all boot-relevant information on a 
smartcard. To the extent this is possible , boot 

10 integrity will be maintained. BITS is not a virus 

checker , however, for those files whose signatures are 
stored on the smartcard, it is possible to detect the 
modification of the file on the host system. Thus the 
user may be notified that an executable is suspect before 

15 it is run. In general BITS will provide enhanced 

computer security by utilizing the secure storage and 
processing capabilities inherent to the smart card. 

From a security perspective, the less that a user 
depends upon from a shared environment, the better. Any 

20 shared writable executable may potentially contain 

malicious code. Fortunately, advances in technology are 
likely to permit the storage of entire operating systems 
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as well as utilities on a smartcard, thus obviating the 
necessity of sharing executables altogether. 

Smartcards themselves may also be made more 
secure. Currently, authentication to the smartcard is 
5 limited to user-supplied passwords. In most systems, 
three consecutive false presentations results in the 
smartcard account being disabled. However, if biometric 
authentication (e.g., fingerprint checks or retinal 
scans) is incorporated into the card, it will be possible 

10 to achieve higher assurance in user authentication. 

To date, the size requirements of smartcards have 
imposed the greatest limitation upon their utility; the 
current state of the art is a 1.0 micron resolution in 
the burning of chip masks. However, SGS Thompson and 

15 Phillips recently announced the development of 0.7 micron 
technology as well as plans for a 0.5 micron technology. 
Regardless of these advances, the chips themselves are 
still currently limited to a few millimeters on a side 
due to the brittle nature of the silicon substrate from 

20 which they are made. A flexible substrate might allow 
chips which occupy the entire surface of the smartcard 
resulting in an exponential gain in computing resources. 

A smartcard with this capability would result in a 
truly portable (wallet-sized) personal computer which 

25 could be made widely available at relatively low cost. 
In this type of computing environment only the bulky 
human interface need be shared. A computing station 
might consist of a monitor, a keyboard, a printer, and a 
smartcard interface. The user could walk up to the 

3 0 computing station, supply the CPU and data storage, and 
begin work. 

The implications of this technology are 
impressive. The existence of instant PC access for 
millions regardless of location would greatly enhance the 

35 utility of computers. The ability to use the same 
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environment; wherever one chooses to work would eliminate 
time spent customizing and increase productivity. The 
security provided by smartcards may also result in 
increased security for sensitive data by decreasing the 
5 likelihood of compromise or loss. 

Because of the mode in which the invention is 
used, it might be wrongly compared with a boot from 
floppy disk. While it is true that inserting a smartcard 
is similar to inserting a f loppy, the interaction during 
10 the boot sequence is entirely different • The smartcard- 
based system incorporates two separate authentications, 
user to card and card to host, which are entirely absent 
from the floppy boot. Further, the integrity of the boot 
information on a floppy is protected only by an easily 
15 removed wr ite-protect-tab ; while the smartcard requires 
the authentication of the security officer in order to 
update boot information. One may also note the ease of 
carrying a smartcard as compeared with a floppy disk. 

The invention has been installed and tested on a 
20 desktop computer. However, the system is easily 

generalizable to any computing environment including 
mainframe, microcomputer, workstation, or laptop. The 
intelligent token of choice for this embodiment is a 
smartcard. The reason is that ISO Standard smartcards 
25 are expected to be the most ubiquitous and consequently 
the least expensive form of intelligent token. 

Appendix A r incorporated by reference, is a source 
code listing of the BIOS Extension code loaded onto the 
memory of the addin board (as described above) written in 
30 8088 Assembly language. This code may be assembled using 
a Borland Turbo Assembler (TASM") and linked using a 
Borland Turbo Linker (TttJSK*) , and run on a AT Bus (ISA 
compatible) computer running a DOS compatible OS. 
Appendix A contains material which is subject to 
35 copyright protection. The owner has no objection to 
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facsimile reproduction by anyone of the patent document 
or the patent disclosure, as it appears in the patent and 
Trademark Office patent file or records, but otherwise 
reserves all rights whatsoever. 
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dosbits-asm Paul C. Clark 

BOOT INTEGRITY TOKEN SYSTEM - DOS Version 
BIOS Extension for DOS smart card boot 
Version 1 



ACK 
ETX 
10 NAK 



Useful Defines 
EQU 
EQU 
EQU 



6 Oh 
03h 

OOOEOh 

CX>M1_CTL_REG EQU 0 0 3 FCh 

COMl_DATA_REG EQU 003F8h 
COMl_STAT_REG EQU 003FDh 
STACKAREA EQU 06000h 
15 SCRATCHAREA EQU 07000h 
PBRAddr ess EQU 0 7 CO Oh 
PWDAddress EQU 0C007h 



20 



25 



30 



35 



r 

Cseg 



Org 03h 
after extension 



Segment Para Public 'Code' 
Assume CSrCseg 



;Code starts 



Mov 

Mov 

Push 

Push 

Mov 

Mov 

Mov 

Mov 

Mov 

Push 

seg for small model 
Pop 
Sti 
Cld 



40 



increment 



stack 



Call 

Pop 

Pop 
Mov 



BX f SP 
CX,SS 
BX 
CX 

AX, STACKAREA 

SS,AX 

SP,0000h 

AX, SCRATCHAREA 

ES,AX 

CS 



/signature and length 
;Save stack 



DS 

Main 

CX 

BX 

SS, CX 



;Set up new stack 

;Set scratch area 
;Data seg =• Code 



; Allow breaks 
;Set direction to 



/Restore original 
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Mov SP,BX 
Jmp Intl9Hdl 



/Execute the PBR 



Abort Label Near 

DB OCBh 

5 opcode 

; Mov AH,4Ch 

control to DOS 

; INT 21h 



10 



15 



20 



25 



30 



;Far return 
; Return 



Identify BIOS extension 



DB 
DB 



'ROM BIOS Extension f or DOS BITS ' 
'Version 1 ' 



Main Program 



Main 
port 

for dialog 



subtitle 



card 

35 is inserted 
password 



40 



Proc Near 

Call InitPort 

Call ClrScr 

Call DrawBox 

Mov DX,071Ah 

Mov SI, offset STitle 

Call StrScr 

Mov DX,081Eh 

Mov SI , offset SSTitle 

Call StrScr 

Mov DX , OAlDh 

Mov SI , offset InsrtCrd 

Call StrScr 

Call WaitCard 

Call GetPwd 



Mov AX, SCRATCHAREA 
Mov ES,AX 
Call ReadPbr 



/Initialize COM 

; Clear screen 
;Draw the frame 



; Display title 
/Display 

/Prompt user for 

/Wait until card 
/Get and present 

/Read and 



install PBR from card 

Mov DX,0ClAh 
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MOV 


SI , offset 


Erase 


; Erase load 




message 










Call 


StrScr 








Mov 


DX,0ClAh 




; Notify user of 


O 


file checking 








Mov 


SI, offset 


FileCnk 






Call 


StrScr 








Call 


Chkio 




; Check IO • SYS 




integrity 








i n 
1U 


Call 


ChkMSDOS 




; Check MSDOS.SYS 




integrity 










Call 


ChkCMD 




; Check 




COMMAND •COM integrity 








Call 


ChkCFGSYS 




; Check 


15 


CONFIG.SYS integrity 










Mov 


DX,0ClAh 








Mov 


SI, offset 


Erase 


/Erase file 




check message 










Call 


StrScr 






20 


Call 


CIrScr 








Mov 


SI, offset 


Power Off 


/Remove power 




from card 







Call CReaderCom 



;PC hangs part, way through boot process 
25 technique! Needs fix! 
; Xor 
19 handler with 
; Mov 
PBR 

30 ; Lea 
where the PBR is 

Mov 
Push 
Pop 



AX, AX 
DS,AX 

AX, PBRAddress 



using this 

/Replace INT 
/address of 
/Jump to 



35 



Mov 
Int 



DS: [0064] ,AX 
CS 
AX 

DS: [0066] ,AX 
1* 



Main 



Ret 
Endp 



40 



Interrupt 19 (Warm Boot) Handler 

- execute PBR loaded from card. 



Intl9Hdl 



Proc 
Sti 



Far 



Copyright rights and all other rights reserved. 



WO 93/17388 



PCT/US93/01675 



0000:7C00 
Intl9Hdl 



DB 

EndP 



- 31 - 
OEAh, OOh, 7Ch f OOh, OOh 



;Far JMP to 



Initialize COK1: 9600, N, 8,1 





InitPort 


Proc 


Near 






Push 


AX 






Push 


DX 


10 












Mov 


AH, 00 




service 0 










Mov 


AL, 11100011b 




parity, 8 


bit data 




15 




Mov 


DX,0000 






Int 


14h 






Pop 


DX 






Pop 


AX 


20 




Ret 






InitPort 


Endp 






;Wait for 


card to be 


inserted 


25 


WaitCard 


Proc 


Near 






Cll 






waxuijoop 


Label 


Near 






Push 


DS 


30 




Mov 


SI, offset InitRdr 




reader 










Call 


CReaderCom 






Mov 


SI, offset StCrdTp 






Call 


CReaderCom 


35 




Mov 


SI, offset InitRdr 






Call 


CReaderCom 






Mov 


SI, offset PowerOn 




to card 










Call 


CReaderCom 


40 




Mov 


SI,0001h 






Mov 


BX , SCRATCHAREA 






Mov 


DS,BX 






Lodsb 








Cmp 


AL,04h 


45 


code is 4 


bytes, 








Pop 


DS 



; Interrupt 14 
;9600 baud, no 
;C0M1: 



;lnitizlize 

;Set card type 
; Reset card 
j Apply power 



there! 



;If return 
;Card isn't 
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Jz 

something is there. 



- 32 
WaitLoop 



/Otherwise 



WaitCard 



Sti 
Ret 
Endp 



;6et password from user and present to card 



10 


GetPwd Proc 


Near 




Push 


AX 




Push 


CX 




Push 


DS 




Push 


DI 


15 


PwdLoop Label 


Near 




Mov 


CX,00h 




character count 






Mov 


DX, 0A1 Ah 




message 




20 


Mov 


SI , offset Erase 




Call 


StrScr 




Mov 


DX, OAlAh 




Mov 


SI, offset PwdPrmpt 




password prompt 


25 


Call 


StrScr 




Mov 


DI , PWDAddress 




Readltoop Label 


Near 




Mov 


SI. offset KbdStat 




keyboard status label 


30 


Mov 


DX, OlOlh 




Call 


StrScr 




Mov 


AH,01h 




keyboard status 






Int 


16h 


35 


Call 


DispStat 




Keyboard Status 






Jz 


ReadLoop 




empty buffer 






Mov 


DX,CX ;Pi 


40 


the right place 






Add 


DX,0A24h 




Call 


CurPos 




Mov 


AH, Oh 




Int 


16h 



; Initialize 

; Erase previous 



/Display 

; Check 

/Display 
; Loop on 

;Put the cursor in 



45 from keyboard 



;Read character 
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<BACKSPACE> 
5 <RETURN> 

10 exceed eight 



Cmp 

Je 
Cmp 

Je 
Cmp 
Je 
Cmp 

Jge 



Stosb 
presentation str 
Inc 

15 character count 

Mov 

Call 

Jmp 



EraseChar 
20 BACKSPACE 

there is? 



Label 

Cmp 

Je 



delete goto read loop 
25 Dec 
before backspace 
Dec 

count 

Call 

30 Mov 

Call 
Mov 
Call 
Jmp 



- 33 - 

AL,08h 

EraseChar 
AL, ODh 

SpaceFill 
AL,lbh 
SpaceFill 
CX,08h 

Beep 



CX 

AL, 'X' 

DisplayChar 

ReadLoop 

Near 

CX f OOh 

Beep 

DI 

CX 

DisplayChar 
AL, ' ' 
DisplayChar 
AL, 08h 
DisplayChar 
ReadLoop 



35 Beep 

continue 



Label Near 

Mov AL, 07h 

Call DisplayChar 

Jmp ReadLoop - 



40 S pace Fill Label Near 
RETURN or ESC 

Mov AL, ' ' 

spaces . 

padloop label near 
45 cmp CX,08h 

Jge Presentpw 
padding, send pw 



; Check for 

; Check for 

; check for <ESC> 
/Length cannot 

; Store as part of 
; Increment 



; Process a 
;Is backspace all 
;if no chars to 
; Remove character 
; Decrement char 



;Ring the bell and 



;User has pressed 
;Pad out pwd with 

; After space 
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Stosb 






Inc 


CX 






padloop 




Presentpw Label 


Near 


5 


;Jinp CodeOK 






Mov 


AX, OCOOOh 




present code cmd 






Mov 


DI f AX 




Mov 


AL. OEh 

fl I J W W Jill* 


10 


Stosb 






Mov 


AX, OOODAh 




Stosw 






Mov 


AX,0020h 




Stosw 




15 


Mov 


AX,0804h 




StoSw 






Mov 


SI, OCOOOh 




the reader 




20 


Mov 


AX, SCRATCHAREA 




Mov 


DS,AX 




Call 


CReaderCom 




Mov 


SI, 0003 


25 


response string 






Lodsb 






Cmp 


AL,90h 




Je 


CodeOK 




Lodsb 




30 


Cmp 


AL,40h 



; Fill-in rest of 



/Present the code to 



(!) 



;Look at the card 

;90h = code ok 

; 9 84 Oh = card locked 



35 



CardLock 



40 



45 



Je 

Mov 
Mov 
Call 
Jmp 

Label 

Mov 

Mov 

Call 

Mov 

Mov 

Call 

Mov 

Mov 

Call 

Mov 

Mov 



CardLock 



DX, OClAh 

SI , offset BadPass 
StrScr 

PwdLoop ;Give it another try 

Near ;Card is locked 

DX, OAlAh 

SI f offset Erase 

StrScr 

DX, OClAh 

SI , offset Erase 

StrScr 

DX,0B20h 

SI , offset CdLck ; Inform user 

StrScr 

DX, OClAh 

SI, offset CdLck2 



copyright rights and all other rights reserved. 



WO 93/17388 



PCI7US93/01675 



- 35 - 



LockLoop 

loop 

CodeOK 
OK. . • 



10 



15 



20 GetPwd 



Call 

Mov 

Call 

Label 

Jmp 



Label 

Mov 

Mov 

Call 

Mov 

Mov 

Call 

Pop 
Pop 
Pop 
Pop 
Ret 
Endp 



StrScr 

SI, off set PowerOff 

CReaderCom 

Near 

LockLoop 



Near 

DX,0ClAh 

SI, offset Erase 

StrScr 

DX,0ClAh 

SI, offset Corrct 

StrScr 

DI 
DS 
CX 
AX 



;Hang in infinite 



; Presentation was 



; Inform user 



/Cleanup and return 



Load partition boot record from card 
ReadPBR 



25 



30 



PBR file 



Proc 
Push 

Mov 

Call 



Mov 
at 7000:C000 

Mov 
Mov 

35 bytes 

Stosw 
Mov 
Stosw 
Xor 

40 Stosw 
Mov 
Stosb 



45 bytes read 



Xor 

Mov 
Label 



Near 
DS 

SI , offset SelPbrFl 

CReaderCom 

AX,0C0O0h 

DI , AX 
AX,0DB06h 

AX, 0B200h 
AX, AX 
AL,34h 

DX r DX 

BH,01h 
Near 



; Select the 

;Fonn command 
; Store command 



;Init no. 



RFLoop 
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Mov 


AX, 0C004h 






Mov 


DI,AX 






Mov 


AX,DX 






Mov 


CL, 04b 


5 




Div 


CL 






Stosb 








Cmp 


BH, OAh 






Jne 


SendRdCmd 






Inc 


DI 


10 




Mov 


AL,2Ch 






Stosb 






SendRdCmd 


Label 


Near 






Mov 


SI, OCOOOh 






Mov 


AX , SCRATCHAREA 


15 




Mov 


DS,AX 






Call 


CReaderCom 






Push 


ES 






Xor 


AX, AX 






Mov 


ES,AX 


20 


segment 0000 








Mov 


SI, 0003 




bytes 










Mov 


AX,PBRAddress 






Add 


AX,DX 


25 




Mov 


DI,AX 






Add 


DX,0O34h 






Mov 


CX,001Ah 






Cmp 


BH, OAh 






Jne 


Do Copy 


30 




Mov 


CX,0016h 




DoCopy 


Label 


Near 






Repz 








Movsw 






a time 






35 




Pop 


ES 






Inc 


BH 






Cmp 


BH, OBh 






Jne 


RFLoop 






Pop 


DS 


40 




Ret 






ReadPBR 


Endp 





; Destination 
;Skip header 



;Copy word at 



Check integrity of IO.SYS 



45 ChklO Proc Near 

Mov DX, 0C2Ah 

Call CurPos 

Mov SI, offset Filel 



;Display filename 



Copyright rights and all other rights res rved. 



WO 93/17388 



PCI7US93/01675 



- 37 - 



simulation 



ChklO 



Call 


StrScr 


Push 


BX 


Mov 


BX,0004h 


Call 


Delay 


Pop 


BX 


Ret 




Endp 





; Simple delay for 



10 



Check integrity of MSDOS.SYS 





ChkMSDOS 


Proc 


Near 








Mov 


DX,0C2Ah 




ID 


filename 












Mov 


SI , offset 


S Erase 






Call 


StrScr 








Mov 


DX,0C2Ah 








Mov 


SI , offset 


File2 


on 




Call 


StrScr 








Push 


BX 








Mov 


BX, 0004h 






simulation 












Call 


Delay 




25 




Pop 


BX 








Ret 








ChkMSDOS 


Endp 








; Check integrity of COMMAND.COM 


30 










ChkCMD 


Proc 


Near 








Mov 


DX r 0C2Ah 






filename 








35 




Mov 


SI , offset 


S Erase 






Call 


StrScr 








Mov 


DX,0C2Ah 








Mov 


SI, offset 


File3 






Call 


StrScr 




40 




Push 


BX 








Mov 


BX,0004h 






simulation 












Call 


Delay 








Pop 


BX 




45 














Ret 








ChkCMD 


Endp 







; Erase previous 
/Display filename 
; Simple delay for 



; Erase previous 
; Display filename 
; Simple delay for 
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Check integrity of CONFIG.SYS 



ChJcCFGSYS Proc 

5 

Mov 

filename 

Mov 
Call 

10 Mov 
Mov 
Call 
Push 
Mov 

15 simulation 

Call 
Pop 

Ret 

2 0 ChJcCFGS YS Endp 



25 



30 



35 



40 



SendByte Proc 
45 Push 
Mov 
Push 
Push 



Near 

DX r 0C2Ah 

SI , offset SErase 

StrScr 

DX r 0C2Ah 

SI, offset File4 

StrScr 

BX 

BX,0004h 

Delay 
BX 



Near 
BP 

BP,SP 

AX 

DX 



; Erase previous 
; Display filename 



; Simple delay for 



Busy wait: 

- duration passed in BX 



Delay Proc Near 

Push BX 

Push CX 
DLoopO Label Near 

Mov CX,0000 
DLoopl Label Near 

Inc CX 

Cmp CX , OFFFFh 
■Xne DLoopl 
Dec BX 
Jnz DLoopO 
Pop CX 
Pop BX 
Ret 
Delay Endp 



Transmit byte to COM1: 

— byte passed on stack 
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SendDly 
overrun 



10 



15 



20 SendByte 



Mov 
Label 

Inc 
Cmp 
Jnz 

Mov 

Mov 
Out 

Mov 
Mov 
Out 

Pop 
Pop 
Pop 
Ret 
Endp 



; Delay to prevent 



DX,0000 
Near 

DX 

DX, OOFFh 
SendDly 



DX, COMl_CTL_REG /Indicate send 

AL, OBh 
DX, AL 

DX,COMlJDATA_REG /Output byte to port 

AL,byte ptr [BP+4] 

DX,AL 

DX 
AX 
BP 



Transmit ASCII representation of byte to COM1: 
- byte passed on stack 



25 


ASendByte 


Proc 


Near 








Push 


BP 








Mov 


BP,SP 








Push 


AX 








Push 


DX 




30 




Push 


CX 








Mov 


AL, byte ptr [BP+4] 


;Get byte 






Mov 


AH, 00 






Mov 


CL,04h 








Shr 


AX,CL 


;Arith shift right 


35 




Cmp 


AX, OAh 


/Result > 10 




(A. .F) ? 












Jge 


HAlpha 


/Yes, calc ASCII 




for letter 












Add 


AL,30h 


/No, calc ASCII 


40 


for number 












Jmp 


HSend 






HAlpha 


Label 


Near 








Add 


AL,37h 


/Calc ASCII for 




letter 








45 


Hsend 


Label 


Near 








Push 


AX 
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10 



20 



25 





Call 


SendByte 


calculated 


byte 






Add 


SP,02h 




Mov 


AL,byte ptr [BP+4] 




And 


AX,000Fh 


nibble 








Cmp 


AX,0Ah 


(A..F) ? 








Jge 


LAlpba 


for letter 








Add 


AL,30h 


for number 








Jmp 


LSend 


LAlpha 


Label 


Near 




Add 


AL,37h 


letter 






Lsend 


Label 


Near 




Push 


AX 




Call 


SendByte 


calculated 


byte 






Add 


SP,02h 




Pop 


cx 




Pop 


DX 




Pop 


AX 




Pop 


BP 




Ret 




ASendByte 


Endp 





;Send out 

;Mask out high 
; Result > 10 
;Yes, calc ASCII 
;No, calc ASCII 

;calc ASCII for 

;Send out 



30 ; 



;Get byte from COM1: 

; -byte returned in AL 



35 



RcvByte 



ready 
GetByte 



40 



45 



RcvByte 



Proc 
Push 

Mov 

Label 
In 
And 
Jz 

Mov 
In 

Pop 
Ret 
Endp 



Near 
DX 



DX,COMl_STAT_REG ;Wait for receive 

Near 
AL,DX 
AL, Olh 
GetByte 



DX, COMX_DATA_REG 
AL,DX 

DX 



;Get byte 
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;Get byte from COM1: converting from ASCII representation 
to byte 

-byte returned in AL 
-ETX returns 01 in AH, 00 otherwise 



10 



15 



20 



ARcvByte 



port 



high nibble 



HNumCvt 



RcvLow 
25 in BL 

from port 
nibble 

30 

LNumCvt 



35 



Combine 



40 into byte 

RcvEtx 
45 RcvDone 



Proc 


Near 


Push 


BX 


Push 


CX 


Call 


RcvByte 


Cmp 


AL,ETX 


Je 


RcvEtx 


Cmp 


AL,41h 


«7cre 


HNumCvt 


Sub 


AL, 30h 


Jed 


RcvLow 


Label 


Near 


Sub 


AL,37h 


Label 


Near 


Mov 


BL, AL 


Call 


RcvByte 


Cmp 


AL,41h 


Jge 


LNumCvt 


Sub 


AL,30h 


Jmp 


Combine 


Label 


Near 


Sub 


AL,37h 


Label 


Near 


Mov 


CL,04 


Shi 


BL, CL 


Or 


AL,BL 


Mov 


AH, 00 


Jmp 


RcvDone 


Label 


Near 


Mov 


AH, 01 


Label 


Near 


Pop 


CX 


Pop 


BX 


Ret 





;Get a "byte from 
;Is it ETX? 

;Not ETX, convert to 



; Store high nibble 
;Get another byte 
; Convert to low 



/Combine h/1 nibbles 



;ETX, set AH — 1 
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ARcvByte Endp 



Send NAK to reader/ writer (request retransmission) 



5 


SendNAK 


Proc 


Near 








Push 


AX 








MOV 


Ali, NAK 


; Transmit NAK 






Push. 


AX. 








Call 


ASendByte 


- 


10 




Add 


SP,02h 








Mov 


Ali, 00 


; Command length is 






Push 


AX 






Call 


ASendByte 




15 




Add 


SP,02h 








Mov 


Ali, NAK 


;CRC is just NAK 




byte 










Push. 


AX 




20 




Call 


ASendByte 








Add 


SP,02h 








Mov 


AX,ETX 


/Transmit ETX 






Push 


AX 








Call 


SendByte 








Add 


SP,02h 








Pop 


AX 








Ret 






30 


SendNAK 


Endp 








/Send command to reader /writer 








-check 


response for NAK and 


retransmit if 




necessary 








35 


• 


-pointer to string passed in DS:SI 




CReaderCom Proc 


Near 








Push 


AX 








Push 


BX 




40 




Push 


CX 








Push 


DX 





CommandLoop Label Near 

Push DS 

Push ST 

45 Call Reader com ;Send reader /writer 

command 
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Call 


CGetResp 




response 






Push 


ES 




Pop 


DS 


5 


Mov 


SI, 0000 




Lodsb 






of response 






Cmp 


AL, NAK 




received properly 




10 


Jne 


RecvOK 




recleved OK 






Pop 


SI 




Pop 






Jmp 


CommandLoop 


15 


RecvOK Label 


Near 




Pop 


SI 




Pop 


DS 




Pop 


DX 




Pop 


CX 


20 


Pop 


BX 




Pop 


AX 




Ret 






CReaderCom Endp 





;Get reader /writer 

;Look at first byte 
;NAK? message not 
;Not NAK, message 

;Try again 



25 



30 



35 



40 



Send command to reader/writer 

-pointer to string passed in DS:SI 



length 



length 
45 ComLoop 
byte 



Proc 


Near 


Mov 


AL, ACK 


Mov 


BL, AL 


Push 


AX 


Call 


ASendByte 


Add 


SP,02h 


Lodsb 




Xor 


BL, AL 


Push 


AX 


Call 


AsendByte 


Add 


SP,02h " 


Mov 


CL, AL 


Mov 


DL,00 


Label 


Near 


Lodsb 




Xor 


BL f AL 



/Transmit ACK 
; Store for CRC 



;Load command length 
/Compute CRC 

/Transmit command 



;Loop on command 

;Get next command 
/Compute CRC - 
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Push 


AX 








Call 


ASendByte 


; Transmit command 




byte 












Add 


SP,02h 




5 




Inc 


DL 








Cmp 


DL, CL 








Jnz 


ComLoop 








Push 


BX 


; Transmit computed 


10 


CRC 












Call 


ASendByte 








Add 


SP,02h 








Mov 


AL,ETX 


/Transmit ETX 


15 




Push 


AX 








Call 


SendByte 








Add 


SP, 02h 








Ret 






20 


ReaderCom 


Endp 







25 



;6et response from reader /writer 

; - checks response CRC and requests 

retransmission if necessary 



CGetResp Proc 



RespLoop Label 
Mov 

destination ptr 
30 Call 
string 

Cmp 
Jz 

finished 
35 Call 
request retrans 

Jimp 

RespDone Label 
Ret 

40 CGetResp Endp 



Near 

Near 
DI,0000 

GetResp 

AL,00 
RespDone 

SendNAK 

RespLoop 

Near 



; Initialize 

;Get the response 

;No error, we're 
; Error in response , 



Get a response string from reader /writer 

-response string stored starting at ES:DI 



45 GetResp Proc Near 
CharLoop Label Near 
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10 response 



15 



Mov 

Call 

Stosb 

Xor 

Cmp 

Jnz 

Xor 
Dec 

Dec 

Lodsb 

Xor 

Cmp 



calculated CRC 
Jz 
Mov 

Ret 



error 

20 

RespOK 
error 

25 GetResp 



Label 
Mov 

Ret 
Endp 



BL,00 
ARcvByte 

BL,AL 
AH, 01 
CharLoop 

BL, ETX 
DI 

DI 

BL, AL 

AL,BL 

RespOK 
AL, 01 



Near 
AL,00 



; Initialize for CRC 
;Recieve byte 

; Calculate CRC 
; Repeat until ETX 



; Remove ETX from CRC 
;Get CRC from 



; Remove CRC from CRC 
/Compare with 

/Return AL=01 if 
/Return AL=*00 if no 



Display Contents of AX Register 



30 



DispStat 



35 



40 



Proc Near 
Push CX 
Push BX 
Mov CX,0004h 
Mov BX,AX 

Mov AL, AH 
Shr AL, CL 
Call DispNibble 

Mov AX,BX 
Mov AL, AH 
Call DispNibble 

Mov AX,BX 
Shr AL, CL 
Call DispNibble 

Mov AX,BX 
Call DispNibble 



;Save registers 

/Shift by one nibble 
/Save AX in BX 



/Reset AX 



/Reset AX 



/Reset AX 
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5 DispStat 



Mov AX,BX 
Pop BX 
Pop CX 
Ret 
Endp 



/Reset AX 



Display character and 
-character to 



advance cursor 

be displayed is passed in AL 



10 DisplayChar 

15 should go away) 
0 



20 



count 



25 DisplayChar 



Proc 


Near 




Push 


AX 


;Save contents of AX 


Push 


BX 


;Save contents of BX 


Push 


CX 


;Save character count 


Mov 

) 


AH,0eh 


/Display X's this 


Mov 


BH r 00h 


/Select video page 


Mov 


CX, 01 




Int 


lOh 


/Echo character 


Pop 


CX 


/Restore CX to character 


Pop 


BX 


/Restore BX 


Pop 


AX 


/Restore AX 


Ret 






Endp 







Display nibble - character to be displayed is 
passed in the lower nibble of AL 



30 DispNibble 



35 



letter 



40 



45 DispNibble 



Proc Near 

Push AX 
And AL,0Fh 
Cmp Alt, OAh 
Jge letter 
Add AL,'0' 

Call DisplayChar 

Pop AX /Restore AX 

Ret 

Label Near 
Sub AL, OAh 
Add AL, 'A' 

Call DisplayChar 

Pop AX /Restore AX 

Ret 

Endp 



/Save contents of AX 
/Mask: AL 

/Display A-F not digit 



Send string to screen 

-pointer to string passed in DS:SI 
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-location on screen passed in DX (row, col) 





Strscr 


Proc 


Near 








Push 


AX 




5 




Push 


BX 








Push 


CX 






service 9 


Mov 


AH, 09 


/Interrupt 10 












Mov 


BH,00 


; Video Daae 0 


10 




Lodsb 








Mov 


BL,AL 


;Load attribul 




byte 












Mov 


CX,0001 


;only display 




one of each char 




15 


Scrloop 


Label 


Near 








Call 


CurPos 


t Move cursor- 






Lodsb 










Or 


AL, AL 


•Out* at*/4 r^-P 




string byte? 








20 




Jz 


ScrDone 


;If so, we're 




done . . . 












Int 


lOh 


; Otherwise 




display character 










Inc 


DX 


; Increment 


25 


cursor position 












Jmp 


ScrLoop 


; Repeat with 




next character 








ScrDone 


Label 


Near 




30 




Pop 


CX 








Pop 


BX 








Pop 


AX 








Ret 








StrScr 


Endp 







35 



40 



45 



Draw box frame for dialog 
DrawBox 



Proc 
Mov 
Call 
Mov 
Mov 
Mov 

Mov 
Mov 
Int 



Near 
DX,0517h 
CurPos 
AH, 09 
BH,00 
BL,07 

CX,0001 
AL, 0C9h 
lOh 



; Service 9 
/Primary video page 
; Character attribute 

/Display only one 
; Upper left corner 



Mov 



DX,0518h 



;Top bar 
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10 



15 



20 



25 



30 LSide 



35 



RSide 



40 



DrawBox 



Call 


CurPos 


Mov 


Alt. OCDh 


Mov 


CX, OOlFh 


Int 


lOh 


Mov 


DX. 0537h 


Call 


CurPos 

W»l J 1. .two 


Mov 


AT. OBBh 


Mov 


CX,0001 


Int 


lOh 


nu v 


IV A f \J XZlJL 1 11 


UQ -L J- 




Mov 


AL, 0C8h 


Int 


lOh 


IILlJ V 


UA. f UEil Oil 


v — all 


CurPos 


X!1UV 


Mil f U UUIl 


X AV-J V 


, uuxin 


Tti4- 
XII U» 


JLUI1 


Mov 


DX,0E37h 


Call 


CurPos 


Mov 


AT. flRPH 


ClU V 


cry nnni 


Tnt 


1 vil 


Vnv 
uu V 


DV nfi17h 

f \J\J _L / 11 


Mov 


AT. OB All 


JJCIJJCX 


ncax 


Call 


CurPos 


Int 


lOll 


Add 


DX,0100h 


Cmp 


DX,0E17h 


Jne 


LSide 


Mov 


DX, 0637h 


Label 


Near 


Call 


CurPos 


Int 


lOh 


Add 


DX,0100h 


Cmp 


DX,0E37h 


Jne 


RSide 


Ret 




Endp 





; Upper right corner 



; Lower left corner 



; Bottom bar 



; Lower right corner 



;Left side 



; Right side 



45 



? Clear screen 
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ClrScr 



10 spaces 



15 



again 



20 



25 ClrScr 



Proc 


Near 


Push. 


AX 


Push 


BX 


Push 


CX 


Push 


DX 


Mov 


DX,0000h 


Call 


CurPos 


Mov 


AH. 09h 


Mov 


CX. OSOOh 


Mov 


AT. OP Oh 


Mov 


BH, OOh 


Mov 


BL,07h 


Int 


lOh 


Mov 


DX,0000 


Call 


CurPos 


Pop 


DX 


Pop 


CX 


Pop 


BX 


Pop 


AX 


Ret 




Endp 





;Home cursor 
;Fill screen with 



;Home cursor yet 



30 



35 



40 



Set cursor position 

-cursor row passed in DH 
-cursor column passed in DL 



CurPos 



service 2 



CurPos 



Proc 


Near 


Push 


AX 


Push 


BX 


Mov 


AH, 02 


Mov 


BH, 00 


Int 


lOh 


Pop 


BX 


Pop 


AX 


Ret 




Endp 





; Interrupt 10 
/Video page 0 



45 



Data area 

- Console messages 
— - ISO command strings 
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• ^ - ^_ ^_ _ ^ — — ^_ ^ 

; .Data 



; Console messages 





STitle 


DB 


OAh 


5 


;Char attribute 


(clr) 








DB 


f Boot Infcecrritv Toleen Svat^w' 




; String 








DB 


ooh 




;End of string marker 




10 


SSTltle 


DB 


UAil 






UD 


7 DOS— BITS Version 1' 






DB 


ooh 

u v/xx 




insrtcrd 


DB 


W / XX 






n*R 
uo 


rXcobc in&ciu GcxXTQ. • • ■ 






DB 


uun 




SErase 


DB 


fl"7h 
U /XI 






TATS 
UD 


r r 






r\D 
UD 


uun 




Erase 


DB 


o7h 

U / JUL 


20 




DB 


/ / 






DB 


ooh 

\J If XX 




xrWCLtrXTIipu 


Do 


07h 






UJD 


' Password i ' 






no 


OOh 


25 




r\o 


07h 






DB 


XiiwuiiCvw* rxcaac w»x»jr cx^j cx.JL-1 i • 






DB 






Corrct 


DB 


07h 






DB 


'Xioadincr ODeratincr svstem r 


30 




DB 


OOh 




CdLclc 


DB 


OFh 






DB 


'Card is locked I ' 






DB 


OOh 




CdLck2 


DB 


OFh 


35 




DB 


'Please see Security Manager.' 






DB 


OOh 




KbdStat 


DB 


07h 






DB 


'Keyboard Status: ' 






DB 


OOh 


40 


FileChk 


DB 


07h 






DB 


'Checking files: ' 






DB 


OOh 




Filel 


DB 


07h 






DB 


'IO.SYS' 


45 




DB 


OOh 




File2 


DB 


07h 






DB 


'MSDOS.SYS' 






DB 


OOh 




File3 


DB 


07h 
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DB 


'COMMAND.COM' 




DB 


OOh 


File4 


DB 


07h 




DB 


'CONFIG.SYS' 




DB 


OOh 


BadFile 


DB 


07h 




DB 


'Missing or corrupted 


file!' 






DB 


OOh 


OKFile 


DB 


07h 




DB 


'Files OK. Booting'.. 




DB 


OOh 


; Shared secret 


(card/PC) 


data 


SharSec 


DB 


OOh 



15 /Reader and card command strings 



InitRdr 
StCrdTp 
RstCard 
Poweron 
20 Power Off 
SelPbrFl 



DB 04h, 03h, OFh, ODOh, OAh 

DB 03h, 02h, 02h f OOh 

DB 04h, 03h, OFh, ODOh, OAh 

DB 04h, 6Eh, Olh, OOh, OOh 

DB 01h,4Dh 

DB 06h f ODBh, OOh, 0A2h, 02h, 7Eh, 08h 



; Operating system filenames 



SysFilel 
SysFile2 
25 SysFile3 



DB 
DB 
DB 



'IO SYS' 
'MSDOS SYS' 
'COMMAND COM' 



;£nd, data area 
Cseg Ends 
END 
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What: is claimed is: 

1. A method for reducing the possibility of 
corruption of critical information required in the 
operation of a computer comprising: 

5 storing the critical information in a device , 

communicating authorization information between 
the device and the computer, and 

causing the device, in response to the 
authorization information, to enable the computer to read 
10 the critical information stored in the device* 

2. The method of claim 1 wherein the steps of 
communicating authorization information and enabling the 
computer to read comprise 

a user entering a password, and 
15 the device verifying the password. 

3- The method of claim 1 wherein the 
authorization information comprises biometric information 
about a user. 

4. The method of claim 1 further comprising 
20 storing a password in the device, 

in the device, comparing the stored password with 
an externally supplied password, and 

basing a determination of whether to enable the 
computer to read the stored critical information on the 
25 results of the step of comparing the passwords. 

5. The method of claim 1 wherein the device 
comprises a microprocessor and a memory. 

6. The method of claim 5 wherein the device 
comprises a pocket-sized card containing the 

30 microprocessor and the memory. 

7. The method of claim 1 wherein said critical 
information comprises boot-sector information used in 
starting the computer. 
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8. The method of claim 1 wherein said critical 
information comprises executable code. 

9. The method of claim 1 wherein said critical 
information comprises system data or user data. 

5 10. The method of claim 1 further comprising 

the computer booting itself from the critical 
information read from the device. 

11. The method of claim 1 wherein the computer 
booting itself comprises executing modified boot code in - 

10 place of normal boot code. 

12. The method of claim 11 further comprising 
storing the modified boot code in the form of a BIOS 
extension. 

13. The method of claim 1 wherein the steps of 
15 communicating authorization information and enabling the 

computer to read, comprise 

the device passing to the computer , secret 
information sheared with the computer, and 

the computer validating the shared secret 
20 information passed from the device. 

14. The method of claim 1 wherein the 
authorization information comprises file signatures for 
executable code. 

15. The method of claim 1 wherein the 
25 authorization information comprises a user's 

cryptographic key. 

16. The method of claim 13 wherein the shared 
secret information comprises a host access code. 

17. The method of claim 1 wherein the stored 

30 critical information includes file integrity information. 
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18. A method of booting a computer, comprising 

storing, in a device which is separate from the 
computer, boot information, user authorization 
information, and device authorization information in the 
5 form of a secret shared with the computer, 

providing a communication link between the device 
and the computer, 

receiving possibly valid authorization information 
from a user, 

10 in the device, checking the possibly valid 

authorization information against the stored user 
authorization information to determine validity, 

if the password is determined to be valid, passing 
the boot information and the shared secret information 
15 from the device to the computer, 

in the computer , checking the validity of the 
shared secret information, and 

if the shared secret information is valid, using 
the boot information in booting the computer. 
20 19. A method for initializing a device for use in 

reducing the possibility of corruption of critical 
information required in the operation of a computer 
comprising: 

storing the critical information in memory on the 

25 device, 

storing authorization information in memory on the 
device, and 

configuring a microprocessor in the device to 
release the critical inf ozonation to the computer only 
30 after completing an authorization routine based on the 
authorization information. 

20. The method of claim 19 wherein said critical 
information comprises boot information. 
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21. The method of claim 20 further comprising 
storing file integrity information in the memory of the 
device . 

22. The method of claim 20 further comprising 
5 storing system or user data in the device. 

23. The method of claim 20 further comprising 
storing executables in the memory of the device. 

24. A portable intelligent token for use in 
effecting a secure startup of a host computer comprising 

10 a housing , 

a memory within said housing, the memory 
containing information needed for startup of the host 
computer, and 

a channel for allowing the memory to be accessed 
15 externally of the housing. 

25. The token of claim 24 wherein said memory 
also contains a password for authorization, said token 
further comprising 

a processor for comparing the stored password with 
20 externally supplied passwords. 

26. The token of claim 24 wherein the memory 
stores information with respect to multiple host 
computers . 

27. The token of claim 24 wherein said housing 
25 comprises a pocket-sized card. 
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